This invention relates to asynchronously-operating systems in which synchronous processes can be selectively invoked. More particularly, the invention relates to an asynchronous transaction processing system which also supports the selective invocation of synchronous transaction processes.
Transaction processing characteristically involves a system in which a central transaction processor (XP) is connected, on a time sharing basis, to a multiplicity of user terminals which access the transaction processor for the purpose of conducting transactions Relatedly, a transaction is an exchange between a terminal and the transaction processor that accomplishes a particular action or result. For example, in banking transaction systems, an automatic teller (user terminal) may be used to effect the withdrawal of funds from a customer's account and the updating of the customer's account balance to reflect the withdrawal. Transaction processing is covered in detail in Chapter 18 of the work by C. J. Date entitled "AN INTRODUCTION TO DATABASE SYSTEMS, VOLUME ONE," Addison-Wesley, 1986.
A transaction necessarily involves an application process in the transaction processor which is dispatched to conduct a transaction in response to input data provided by a message from a user. As with any other computer process, an application process involved in a transaction consists of receiving the input, processing the input, and generating an output signifying the transaction response to the input. In an on-line multi-terminal transaction processing system, a system user engages in a transaction by inputting data into the system directly from one of the terminals connected, through a communication node, to the transaction processor. The response is transmitted from the processor back to the point of origin of the input data.
In a synchronous environment, after inputting transaction data, a terminal is "held" by the application program conducting the transaction while the transaction processing is performed, and is released when the response is transmitted to the terminal. A terminal is "released" by transmission to the terminal of a release message containing a code which unlocks the terminal keyboard at the terminal and restores the terminal to an unused ready condition, thereby permitting the user to enter other messages. In an asynchronous environment, the terminal may be released before the response to the originally-initiated transaction is received. If the transaction requires synchronism, preferably the terminal is not released until the response is generated; then, the terminal release and the transaction response are transmitted simultaneously.
Frequently, a synchronous transaction involves a conversational mode of operation in which a sequence of alternating entries and responses between the terminal user and the transaction processor takes place. In a conversational transaction, a terminal should be held by the executing application program until all of the entry/response iterations are completed. When released, the terminal is free to initiate another transaction.
If the terminal is engaged in an asynchronous transaction, the application program can release it prior to input processing and response generation. When released, a terminal can initiate another transaction, await the response of the current transaction, or view responses from other transactions which are queued for output to the terminal. Thus, asynchronism in the transaction processing context means essentially that, once a terminal is used to initiate a transaction, it is disconnected from the transaction executing process. While the transaction processor is provided with a means for returning the response to the terminal, other response data from various sources may also be generated for transmission to the terminal in a nonpredictable sequence.
It is known that an on-line transaction processing system can operate to selectively provide a terminal user with either synchronous or asynchronous connection to an application program. Such selection is normally an artifact of initiating a transaction supported by one of two or more independent subsystems in the transaction processor. For example, a transaction processor can include a pair of database management systems (DBMS) such as the customer information control system (CICS) and information management system (IMS), both software products available from IBM, Armonk, N.Y. As is known, the transactional complement of the IMS includes both synchronous and asynchronous transactions, while the CICS supports only synchronous transactions.
Synchronous transactions are normally used for high priority, short-duration processes. For example, a terminal user may wish to retrieve or update a particular record in a file.
Asynchronous transactions are best suited for low priority, long-duration process where the retention of the terminal until response is delivered would result in inefficient operation. An example of this type is a request that may retrieve a large number of records for inspection, select some subset based on user specified criteria, sort the subset in a user specified sequence, route the list to a device for printing, and respond to the requestor when the list had completed printing.
In a transaction processing system supporting both synchronous and asynchronous transaction processing, it is desirable to permit a user to initiate concurrent execution of synchronous and asynchronous processes. This will permit a user to initiate one or more long-term (asynchronous) processes and, while awaiting a result from the processes, initiate synchronous processes in order to make more effective use of on-line time.
The implementation of a transaction facility compounding synchronism and asynchronism most frequently takes place in the context of a transaction processor controlled by an asynchronous operating system. The multiple virtual storage (MVS) system available from IBM is the principal example of such an operating system. MVS is a multiprogramming operating system which can support the concurrent execution of a variable number of transaction processes. When a message is received from a terminal, it is edited as necessary and the required transaction function is identified. At the same time, the terminal is released to perform more input operations or to receive output transmissions from the transaction processor. As input from the terminal is processed and responses generated, control of the terminal may be reacquired for transmission of the responses. Such a mode of operation is necessary to support the asynchronous IMS functions, message switching, bulk data transfer, printer spooling, and other such asynchronous applications.
For interactive synchronous operations, the desired effect is to initiate the transaction, have it processed, and receive the response before continuing with the next operation. In an asynchronous operating environment, it is possible for a user to enter a synchronous request and then, before the response is generated, receive a message from a different, asynchronous process such as a message switch from another terminal or the reply from a prior asynchronous transaction. This has the appearance of a wrong answer to a request and may be confusing to an inexperienced system user. Another disadvantage of the asynchronous method of system operation occurs when an asynchronous transaction requires a long time to respond. An impatient operator may enter a request and, while awaiting a tardy reply, reenter it one or more times. Since the terminal is released in the asynchronous environment, a sequence of substantially identical transactions is conducted which can lead to improper data update and confusion of a user as the identical replies are displayed in a corresponding response sequence.
Solutions to the problem of providing for synchronous transaction processing in an asynchronous operating environment exist in the prior art. For example, U.S. Pat. No. 4,410,940 of Carlson et al. describes a method permitting cooperating sequential processes to pass control among themselves as they progress to termination. Such passage of control is founded upon a prior knownledge of process input and cannot accommodate the random arrival order of transactions.
Another method of imposing synchronism on an essentially asynchronous operating system is known as "bracket protocol." A bracket is treated by an asynchronous operating system as defining an uninterruptable unit of work consisting of one or more input/response exchanges between the transaction processor and a terminal. The first input of the first exchange in the unit includes a header that indicates "begin bracket," and the final output indicates "end bracket." Essentially, acceptance of the "begin bracket" locks the communication path between the terminal and the transaction processor and imposes a DEMAND/RESPONSE protocol to a transaction until the end bracket occurs. In this regard, the bracket control is also a form of input management in that it prevents the execution of any other transaction processes until the final bracket releases the lock. Further, since the bracket method is terminal-oriented, it requires either that extra intelligence be provided to a terminal or that a user have the level of skill necessary to use the method.
In view of the increasing mixture of synchronous and asynchronous processes in transaction processors which include asynchronous operating systems, there is an obvious need for a technique that provides an effective means for supporting synchronous transactions without preventing concurrent completion of executing asynchronous transactions. It is evident that the self-scheduling and bracket techniques of the prior art are not equipped to meet this need.